Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use G38.3 in qt_auto_probe_tool.ngc to be able to check probe status. #2562

Open
wants to merge 1 commit into
base: 2.9
Choose a base branch
from

Conversation

petterreinholdtsen
Copy link
Collaborator

@petterreinholdtsen petterreinholdtsen commented Jul 2, 2023

There is a test after one of the G38.2 in question that look like this:

O500 IF [#5070 EQ 0]
G90
O500 return [-3] ; indicate probe contact failure to epilog
O500 endif

But the manual state that "If the probing operation failed, G38.2 and G38.4
will signal an error by posting an message on screen if the selected GUI
supports that. And by halting program execution.". When I try to include a similar
test in my test program, the program is aborted and the test is never executed.
This make me believe the wrong G code is used. Or is there something special
about the M6 remapping environment that make G38.2 behave differently?

Made sure both calls to G38.2 are changed to G38.2 with a test verifying the
status.

Also adjusted the handling of the measured height to take any coordinate system
offsets.

@c-morley
Copy link
Collaborator

c-morley commented Jul 3, 2023

These code changes seem good to me - have you tested the error process on a machine or sim?

@petterreinholdtsen
Copy link
Collaborator Author

petterreinholdtsen commented Jul 3, 2023 via email

There is a test after one of the G38.2 in question that look like this:

  O500 IF [#5070 EQ 0]
  G90
  O500 return [-3] ; indicate probe contact failure to epilog
  O500 endif

But the manual state that "If the probing operation failed, G38.2 and G38.4
will signal an error by posting an message on screen if the selected GUI
supports that. And by halting program execution.".  When I try to include a similar
test in my test program, the program is aborted and the test is never executed.
This make me believe the wrong G code is used.   Or is there something special
about the M6 remapping environment that make G38.2 behave differently?

Made sure both calls to G38.2 are changed to G38.2 with a test verifying the
status.

Also adjusted the handling of the measured height to take any coordinate system
offsets.
@petterreinholdtsen
Copy link
Collaborator Author

petterreinholdtsen commented Jul 5, 2023 via email

@c-morley
Copy link
Collaborator

c-morley commented Jul 6, 2023

it seems there is also some needed changes in std_glue to get linuxcnc to notice the returned error numbers. Since it's a common library, I just don't know if it would break others relied on behavior.
Still checking that code change yet,

@petterreinholdtsen
Copy link
Collaborator Author

petterreinholdtsen commented Jul 6, 2023 via email

@c-morley
Copy link
Collaborator

c-morley commented Jul 6, 2023

QT because it was built for qtvcp's screens, though it should work for anyone.

@gmoccapy
Copy link
Collaborator

gmoccapy commented Oct 7, 2023

stuttgart meeting says @c-morley should decide on this.

@VectorHasting
Copy link
Contributor

I'm happy to test this, I'm also working on pull request #2706, and @c-morley flagged this request there and asked if I could test. I've been delayed, and I apologize.

But I have questions:

It looks like from the comment at the beginning that the intention was to keep error codes... and I thought that was the difference between G38.2 and G38.3: that G38.2 returns an error code but G38.3 does not. The code has been changed to G38.3 at lines 69 and 79.

But the comment at the beginning seems to include an ambiguous typo:

Made sure both calls to G38.2 are changed to G38.2 with a test verifying the status.

Assuming what was meant is "change G38.2 to G38.3" I'm wondering if that will defeat getting an error message back??
Or, if the intention was to stop getting the error back, then why?

Those questions aside: how do I test this?

We are only talking about testing the QtDragon GUI, right? Or is this routine used in the other GUIs? (I've been using it on QtDragon)

My thought is to set up my machine so that the _ini[VERSA_TOOLSETTER]MAXPROBE is too small to get from the _ini[VERSA_TOOLSETTER]Z down to the probe surface. Then I would set myself up to issue a T2M6 command. That will call this remap code and I should get an error back to the GUI because it won't be able to get a probe signal while it's doing line 69 or line 79 (since the backoffdist will be heading up from the insufficiently low maxprobe).

Another thought: while I like very much the logical completeness of having the o600 section to check for the error after the reprobe... I nonetheless find myself wondering how that would actually every happen? There would have to be a probe failure of some kind between the success of line 69 and the start of line 79, otherwise 69 would have already failed. In fact, in order to test it, I think I would have to move the probe out of the way after the rapid probe and before the slow reprobe could get there. Hmmm. Not sure I want to try that, mine is bolted on an upright support.

Which, btw, brings me to: I have already gotten this error loads of times when my maxprobe distance is insufficient to reach the tool-setter. So, again I'm wondering if this switch to G38.3 is what is intended here, since it's been working for me without this change. On the other-hand, I'm hesitant about my knowledge here, so I'm very ready to be set straight, and thank you in advance.

Please advise :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants